Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

Driving Social Value Through Business Analysis

Demilade — Thu, 18 Sep 2025 06:40:00 GMT

When people discuss business analysis, they typically think of requirements, processes, or systems. But one of the most rewarding projects I’ve worked on was very different: improving how my company reported its social value.

Social value is about the positive impact an organisation makes beyond profit, things like sustainability and community engagement. Reporting on this sounds simple, but in practice, it’s messy. Social value data resides in various locations, teams often disagree on what constitutes value, and the process can become a time-consuming exercise in copy-pasting and reconciliation. That was the situation I walked into.

My role was to bring order: to make social value reporting clear, consistent, and aligned with the TOMS (Themes, Outcomes and Measures) framework, which is the UK standard for measuring social value.

The Challenge

Now, this project was an interesting one because it had been running without a business analyst for over 2 years, based on the initial assumption that it was a simple reporting project and all social value data was readily available. The first thing I noticed was how fragmented everything was. One team had a spreadsheet for apprentice data. Another team tracked veteran data in emails. The sustainability team had their own systems entirely. When month-end and year-end came around, pulling it all together felt more like detective work than reporting.

Even worse, there was no agreement on what each TOMS metric actually meant. For example, one TOMS metric we were to report on was the organisation’s spend within local VCSEs, and I remember validating that metric with the data owner, and they threw me a curveball by asking me what our definition of “local” was.

So this wasn’t just an internal challenge. Clients and regulators wanted clear evidence of impact, and the company risked underselling and misrepresenting the great work it was already doing. So we were faced with the problem of automating the reporting and secondly auditing the data to prove data integrity to regulators and auditors.

My Role as a Business Analyst

I started by listening. I met with corporate social responsibility leads, finance, supply management, and operations to understand what they tracked and why. Those conversations made one thing clear: everyone cared about social value, but they all saw it from different perspectives without appreciating the bigger picture, like how the data they were responsible for contributed to the bid win rate and the company’s performance against the TOMS framework. their own lens.

To move forward, I facilitated workshops with the various data owners where we mapped out the as-is reporting processes, highlighting data sources and formats. Seeing the flow together, how social value data was captured, how it was stored, and where it got lost, helped people realise why reports were inconsistent. I identified bottlenecks and gaps which the business had to address to allow for reporting automation.

From there, I re-baselined requirements to ensure they reflected both the company’s current strategic goals and the practical realities of reporting. My role was about translation, bringing clarity to chaos.

The Solution

The organisation had over 150 TOMS metrics that they wanted to report on. So you can imagine I had to negotiate with the project sponsor and relevant stakeholders to prioritise 20 TOMS initially for the MVP build. Doing this helped the project team align and narrow on scope.

We agreed on a standardised reporting template of TOMS metrics: volunteering hours, local sourcing, sustainability initiatives, training programs, and a few others. Each department knew what they were responsible for, and how it would be measured and what was required in order to verify the data.

Because it’s one thing to say we are employing X amount of veterans, but how do we actually prove that what we say is true?

On the technical side, we moved away from chasing spreadsheets and emails. Data collection was integrated into existing systems, where we pulled relevant data into the standardised reporting template. A central reporting platform was built so teams could see their contributions in near real time instead of waiting until the end of the month. To protect sensitive data, access was controlled using MFA and role-based access.

This wasn’t just about efficiency. For the first time, social value reporting felt like part of the business rhythm rather than an afterthought.

The Impact

The difference was clear almost immediately. A reporting cycle that used to take nearly three weeks could now be done in under a week. Reporting errors dropped because the numbers were coming from standardised inputs instead of being retyped multiple times.

The bigger win was credibility. Clients could see clearly how the company was delivering on its commitments as we were able to show our company’s social value performance against a national benchmark using the TOMS framework. Internally, leadership started using the data to guide decisions, like investing more in initiatives that had the biggest measurable impact, such as a reduction in plastic use and carbon emissions, which were part of the organisation’s net zero initiative.

What started as a compliance requirement turned into something more valuable: a tool for telling the company’s story and strengthening its reputation amongst competitors.

I’m also going to toot my horn here because this was a clear example of why Business Analysts are needed on projects. For over two years, the project had run without direction, but within just two weeks, I was able to bridge the gap between teams, bring clarity, and give the project the focus it needed. This not only unblocked delivery and achieved the required impact, but also influenced lasting change. As a direct result of lessons learned, a new and improved demand intake process was introduced to properly scope projects before they were taken on, strengthening how reporting was managed across the business going forward.

Insights for Other Business Analysts

Looking back, a couple of takeaways that stand out that might help other BAs facing similar issues:

Get alignment early. If people don’t agree on what “value” means, no amount of process or technology will fix the problem.
Make it visible. People typically tend to understand things better when it’s presented to them visually. I used red to highlight manual interfaces between systems. This trick helped me highlight the reality of the situation to stakeholders
Build for change. Social value expectations will keep evolving—your framework should be flexible enough to grow. Remember, we had an initial 20 TOMS. What happens if the business wants to introduce new social value metrics? I ensured that the solution being developed was easily scalable to the remaining existing TOMS and new TOMS by capturing it as a non-functional requirement and performing requirements traceability to ensure it was considered, handled and delivered by the developers
Consider more than just compliance. Reports can be effective tools for storytelling and engagement, and they are not only for auditors. In my case, the company could now highlight their dedication to social value in their bids, setting them apart from competitors.
Security first mindset. In all you do, always employ a security-first mindset. Think about user/role access early on. I know it may seem daunting, but it saves you a lot of time and effort further down the line.
Verify, verify, verify: when joining a project midway, try to understand the business needs first. This would guide you along. Also, verify whatever information you are provided in the already existing documentation and ensure you get sign-off on every artefact you create. In my case, there were some inconsistencies with identified data sources, and the previous requirements were too high-level, leaving room for ambiguity.

The Bigger Picture

This project reminded me that business analysis isn’t just about requirements, systems or workflows. At its best, it’s about helping organisations define what matters, measure it properly, and act on it.

For me, this showed that we as BAs can play a role in shaping not just business outcomes but also social impact. And in a world where clients and communities care deeply about both, that’s work worth doing.

Author: Demi Adeyemo

Demi is a startup founder and business analyst specialising in technology, data, and digital innovation. He has delivered solutions across finance, social value, HR, education, food services, and facilities management, helping organisations solve complex business problems and achieve measurable impact. With an MSc in Data Science & Artificial Intelligence, Demi applies his technical expertise to drive business transformation and AI adoption.